Navigating hierarchically organized information

ABSTRACT

Hierarchies are navigated easily through a user interface that is continuous in its presentation of node information and may be implemented using a small display space.

BACKGROUND

This invention relates to a user interface for navigating a set ofinformation arranged hierarchically, even a very large set.

In a typical hierarchy or “tree” of nodes, each “node” is connected tozero or more “child” nodes and to one “parent” node, except for one“root” node, which has no parent.

Hierarchies are common in data processing. Often a hierarchy provides aclear way to organize a large amount of information so that a user canfind a particular piece of information. Generally, a user “navigates” atree by iteratively viewing descriptions of a selected node'sneighboring nodes and selecting one of the neighbors until the soughtinformation is found.

A user navigates the Windows file system hierarchy, for example, byiteratively viewing a directory—the file names and subdirectory namesare these neighbors' “descriptions”—then selecting a neighboringdirectory to view, until the sought file is found. Windows offersmultiple user interfaces for the viewing/selection process: afile-selection dialog in applications; successive directory viewsstarting with “My Computer”; a “tree view” in Windows Explorer; and evena command line shell which permits displaying and changing the “current”directory.

Other, richer user interfaces for presenting and navigating hierarchieshave been proposed. Some, such as “cone trees”, attempt to representmuch of a hierarchy using 3D effects to convey relationships on acrowded display. Several use “focus+context” techniques; that is, theportion of the hierarchy upon which the user is currently focused, suchas a current directory, is presented in full, and portions further fromthis focus are presented with progressively less detail. This can beachieved by wrapping a 2D representation of the tree about a curvedsurface and shading parts of the view away from the focus (these twotechniques create a “fish-eye lens” effect), by fractal techniques, orby nesting boxes so that rectangles representing child nodes fill therectangle representing the parent. (“tree-maps”). Some techniques depictthe nodes as objects in a 3D landscape, with more distant nodesappearing smaller.

As for navigation, a theme which is common from “tree view” to“tree-maps” is to detect user input selecting a node (as by a mouseclick “on” the node) and redraw the view of the hierarchy with theselected node as the new “focus”. A few user interfaces portray thechange in views with an animated sequence of intermediate views tosuggest an object-like persistence. Some user interfaces, e.g. the 3Dlandscapes, allow a mode of navigation where the hierarchy view changescontinuously, suggesting flight over the landscape.

Hierarchically organized information is ubiquitous. Computer filesystems, dictionaries, indexes, tables of contents, and XML documentsare hierarchical. The functions available in some applications areorganized hierarchically in menus. On the web, many portals and retailsites are organized hierarchically. Web sites are not constrained to behierarchical, but, again, hierarchy is a clear way to organize largeamounts of information.

SUMMARY

In general, in one aspect, the invention features identifying ahierarchy position in a space defined by a hierarchy of nodes. The spacehas at least two dimensions. Each node is uniquely identifiable withinthe space by values in the respective dimensions, including a node levelidentifying the node's hierarchy level and a node-in-level identifyingthe node uniquely among nodes in that level. The hierarchy position isidentified by position values in the same dimensions. Position valuesneed not correspond to actual node level or node-in-level values.

Implementations of the invention may include one or more of thefollowing features.

The position values may include depth value and position-within-levelvalues both in the form of non-integral numbers. Theposition-within-level value may include a node-in-value valueidentifying one node plus a floating-point number representing an offsetof the position from that node. The hierarchy position may be used toidentify a focus of a user's view of the hierarchy.

In general, in another aspect, the invention features displayingrepresentations of nodes of a hierarchy in a space on a display, eachnode representation fully occupying a subspace within the space, andallocating the space entirely to the subspaces.

Implementations of the invention may include one or more of thefollowing features. The nodes are organized in levels in the hierarchyand the space is allocated among the levels so that one level is fullyrepresented in a dimension of the display that corresponds to changinglevels. The levels of the hierarchy above and below the one level are atleast partially represented. Each of the levels is represented as a bandin the space. Nodes represented in one band have a parent-childrelationship with nodes represented in an adjacent band. Within a band,space is allocated so that the subspace of a parent has the samedimension along the band as the sum of the dimensions of its childrenalong the adjacent band.

In general, in another aspect, the invention features rendering acontainer associated with the node and a representation of informationassociated with the node. The container has dimensions that change withan amount of space dynamically allocated to the node based on a changingfocus in the hierarchy. The representation has unchanging dimensions.The container and the representation are drawn on a display. When thefocus changes, the container is re-rendered with updated dimensions anddrawn on the display. Without re-rendering, the rendered representationis recopied to a new location.

In implementations of the invention, the drawn container indicates thenode's position in the hierarchy and its relationship to nearby nodes,and the representation includes graphics or text or both.

In general, in another aspect, information is received indicating adisplacement of a user input device within a two-dimensional frame ofreference. Displacement in at least one of the dimensions is translatedto a rate of change of a hierarchy position used to identify a focus ofa user's view of the hierarchy.

In general, in another aspect, the invention features displaying arepresentation of a portion of a hierarchy of nodes to a user. Each nodemay have associated an action to be performed by an application, theaction being other than navigation of the hierarchy. A user navigates inthe displayed representation of the portion of the hierarchy by using afirst type of action. The user triggers the action associated with adisplayed node of the hierarchy by invoking the node using a second typeof action.

In implementations of the invention, the first type of action may bedragging and the second type of action may be clicking.

In general, in another aspect of the invention an emulation of areturn-to-center input device enables a user to navigate the hierarchy.The user manipulates a non-return-to-center input device to indicate anintended manipulation of the emulation for purposes of navigating thehierarchy. The user's manipulation is treated as a manipulation of thereturn-to-center input device.

Implementations of the invention may include one or more of thefollowing features. The non-return-to-center input device is a computermouse, trackball, or pad. The return-to-center input device is ajoystick. The emulation includes rendering the device on a display. Theresponse to the user manipulation is to change a focus position in thehierarchy. The focus position is changed by periodically adding a focusincrement vector to a focus position, the focus increment vector being afunction of the vector by which the emulated controller is displacedfrom its center or rest position. The user manipulates thenon-return-to-center controller in a single dragging action to view anarbitrarily large hierarchy of nodes. The function is nonlinear topermit the user to vary navigation velocity over a wide two-dimensionalrange.

In another aspect, the invention features displaying information at aclient about a portion of a hierarchy of nodes including a node at thetop of a sub-hierarchy of the hierarchy. As a user's navigation causessub-hierarchies to approach view in the displayed information,information about the sub-hierarchy that is approaching view is fetchedfrom a server.

In another aspect, a request is received at a server from a client for ahierarchy definition. In response, the client is provided a portion butnot all of the hierarchy definition, the portion referencing otherportions of the hierarchy.

In implementations of the invention, the size of the portion to beprovided to the client may be determined adaptively based on parametersfor optimizing communication between the server and the client. Theserver may automatically build a hierarchy definition portion that is asnear as possible in size to a given minimum portion size. The server maygenerate references to sub-hierarchies and include them with definitionsof nodes of the portion provided.

In another aspect, a web page includes an area that provides anavigational interface to permit continuous navigation of a hierarchy ofnodes of, e.g., links to other web pages.

In another aspect, a user interface includes a device that permitscontinuous navigation for selecting from a hierarchy.

In implementations, the hierarchy may include a function menu, a filesystem, an XML document, an index constructed from a document, list, ortable, an encoded hierarchy, the Dewey Decimal System, categorizedproducts, postal addresses or other location by geographic region, acharacter set to be selected for text entry, or a corpus which is nothierarchical in its native form and upon which hierarchy has beenimposed using a similarity-seeking technology.

Among the advantages of the invention may be one or more of thefollowing.

An indefinitely large hierarchy may be navigated. The interface permitsfast navigation of the hierarchy.

The interface reduces the cognitive load to the user in at least thefollowing ways.

The user is offered a simple metaphor of the hierarchy as a continuousplane, the view of which can only change smoothly as the user navigates.The user is spared abrupt, jarring (to novices, frightening) changes inview by allowing direct control over rate of change of focus, so thatthe view of the hierarchy changes smoothly over time. Any effects ofsuch discontinuities in the view as are necessary are minimized by beingsplit into smaller discontinuities distributed over time. The nodes in alevel do not appear full blown all at once, but appear first as smalloutlines, with detail arriving at different times for different nodes.

The user is not burdened with separate controls for scrolling, forrotation, or for zooming—all navigation is done with one intuitivecontrol with a simple physical metaphor. The single control functionallyreplaces, for instance, the four scroll buttons, two sliders, andnumerous buttons labeled “+” or “−” in Windows “TreeView”. The interfacein this way reduces repetitive hand and eye movements as well ascognitive demands.

The relationship between parent and child nodes is made apparent tofirst-time users by depicting parent nodes as containing the childreninstead of by drawing ambiguous connecting lines.

The interface is frugal with respect to available computer display “realestate”. Space is allocated extremely efficiently, freeing most of atypical computer display for other tasks.

The interface requires only a small implementation size. The algorithmsfor hierarchy rendering can be realized in compact code for low memoryuse and fast delivery over a network.

The interface is frugal with respect to hierarchy-loading bandwidth.Hierarchy information —which can be of indefinite size—is transferred insmall portions on demand as the user “approaches” them. A user cannavigate all levels of a huge hierarchy, acquiring a sense of its size,having caused only a small fraction of the hierarchy information to beloaded.

The interface is especially useful in “World-Wide Web” applications.Novice users distracted by advertisements have a lower capacity for newmetaphors and surprising changes of view. The interface accommodates theuser's expectation that web navigation is to be effected with a small“navigation frame” on the left. The code implementing the user-interfacefor the web is compact enough to be downloaded with a page (as anapplet) which accommodates the user's resistance to installing“plug-ins”. The web surfer need not wait for the information describinga huge hierarchy to be loaded over a slow network.

Each node can have a distinct text and/or graphical representation.Associated with each node can be an apparent way to execute a distinctaction apart from navigation when the node is selected.

The hierarchical structure, text and/or graphical representation of eachnode, and action associated with each node, are defined in humanreadable formats. This hierarchy definition may be requested anddelivered incrementally and on demand. The delivery is a special case of“streaming” data in which the data are dispersed in two dimensions andthe order in which the data are required cannot be predicted withconfidence.

Other advantages and features will become apparent from the followingdescription and from the claims.

DESCRIPTION

FIG. 1 illustrates relationships in a simple hierarchy.

FIG. 2 illustrates an allocation of display area to a portion of thesample hierarchy, arranged in the horizontal direction.

FIG. 3 illustrates an allocation of display area to a portion of thesample hierarchy, arranged in the vertical direction.

FIG. 4 shows a hierarchy view-and-control loop including the user andthe invention in a computer network context.

FIG. 5 is an overall flow diagram.

FIG. 6 illustrates concepts involved in allocating one dimension of thedisplay area to hierarchy levels.

FIG. 7 shows logic involved in reallocating that dimension.

FIG. 8 illustrates concepts involved in allocating a level's displayallocation to nodes within that level.

FIG. 9 shows logic involved in that allocation.

FIG. 10 and FIG. 11 illustrate a process of rendering a portion of thehierarchy.

FIG. 12 illustrates a subroutine used to draw a node at one level andits children.

FIG. 13 illustrates a subroutine used to draw a node at another level.

FIG. 14 illustrates logic used to load hierarchy information from aserver.

FIG. 15 illustrates how a “control stick” can be emulated and showsalternate appearances of emulated controllers.

FIG. 16 shows a sample sequence of views presented to a user navigatinga hierarchy by nudging the control stick at the bottom of the view,where the implementation is configured horizontally with the top of thehierarchy at the top of the view.

FIG. 17 shows a sample sequence of two views presented to a usernavigating a dictionary, where the implementation is configuredvertically with the top of the hierarchy at the left side of the view.

FIG. 18 shows a hypothetical deployment at a single web site to allowrapid seamless navigation of that site.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 illustrates relationships that can exist among nodes comprising ahierarchy 18 and introduces some naming conventions. Each node has zeroor more “child” nodes, and each node has exactly one “parent” nodeexcept for the “root” node 20 which has no parent node. For instance,node 26 is the child of node 24, which is the parent of two nodes 26,27. It will be useful later to number children from left to right; node26 thus has a “child index” of 0 and node 27 has a child index of 1. Anode with no child nodes, like node 22, is called a “leaf” node.

Nodes can grouped by their hierarchy “level”, which we define as thenumber of steps of descent by which they can be reached starting fromthe root node. There are four levels 30 in the hierarchy of FIG. 1.

Implementations of the invention present in a limited display area aview of the hierarchy that can be changed under user control. At any onetime the view is “focused” or centered either at one node or betweennodes, and contains all nodes surrounding this center of view or“Focus”. A user may see one of these surrounding nodes and manipulatethe Focus toward that node so that all nodes surrounding that node arenow in view. By continued navigation of this sort, and exploiting thefact that any node in the hierarchy can be reached from any other nodeby a series of steps through intermediate nodes, the user may view anypoint in the entire hierarchy. Methods discussed below make thisnavigation experience “smooth”—the Focus changes gradually, and theresulting changes in the view are “animated” or rendered in many smallsteps.

FIGS. 2 and 3 show two examples of limited display areas. FIG. 2 shows ahorizontally aligned display area 31, which is efficiently apportionedto nodes about a Focus near Node 24. The Focus is an imaginary point inthe hierarchy that corresponds to the point at the exact center of thedisplay area. In this “horizontal” layout, the nodes of each of thelevels 30 are arrayed horizontally. Because of the small size of thissample hierarchy, some of the display area (33, shaded) is unallocatedfor this particular Focus.

FIG. 3 shows a vertically aligned limited display area as might beparticularly useful in web applications. Here nodes in each of thelevels are arranged vertically, with the top of the hierarchy to theleft of the display area.

For convenience, the rest of this description refers only to thehorizontal layout depicted in FIG. 2.

Referring to FIG. 4, in some implementations based on software residenton a computer 59, a software routine 50 updates both an on-screenrepresentation 52 of an emulated return-to-center controller such as a“joystick” and data representing the emulated controller's displacementfrom its center or rest position. This update is in response to aphysical computer pointing device 66 such as a mouse. A focus updateroutine 54 causes continual updates of internal data representing theuser's focus in the hierarchy. When the focus is updated, a hierarchydraw routine 56 is invoked to render on-screen a representation 58 of aportion of the hierarchy surrounding the focus. (More detailed views ofthe emulated control and the rendered hierarchy are shown and discussedbelow.) Through the user's eye 60 the user's brain 62 continuouslymonitors the evolving hierarchy representation 58 as well as the current“joystick” position 52 over which the user has the feeling of directcontrol, the brain directing the hand 64 to move the physical pointingdevice 66 with its button depressed to effect further change in thefocus and therefore in the portion of the hierarchy visible to the user.In this manner:

-   -   The user quickly learns through continuous feedback how to        manipulate the rendered hierarchy to view beyond any node        currently shown, and by iteration and the fact that all nodes        are connected, to view the entire hierarchy.    -   No abrupt changes in rendering can occur and no abrupt changes        in user hand or eye position are necessary.

In a network environment, a software component 70 of the invention isable to load hierarchy information from a remote hierarchy server 72 byway of a network of computers 74 onto the computer 59, which mayrepresent a client of the hierarchy server. Typically a server willserve many clients concurrently. Hierarchy information loading 70 isdescribed in more detail below with respect to FIG. 14.

Referring to FIG. 5, starting at step 100, a software implementationinitially performs some gathering 102 of configurable parameters whichmay include the display area dimensions and a network source for thehierarchy information. This is followed by initialization 104 of othervariables. In step 104, a dummy root node is created and the hierarchyinformation source is associated with it. Step 104 also initializes theuser “Focus”—the center of that portion of the hierarchy drawn on thescreen—to a point near this dummy root node, which is all that exists ofthe local hierarchy data at this time. Next, the hierarchy loader 70 islaunched to asynchronously load hierarchy is information using standardnetwork protocols from the configured source. The flow of hierarchyloading is described in more detail below with respect to FIG. 14. Fornow we note that: the source may exist on a remote server 72; theinformation may arrive following user—perceptible delay; and asinformation about a node arrives, it is added to the local hierarchydata.

The software next initializes 108 the emulated joystick and itson-screen representation. Next routines 120-126 are launched toasynchronously monitor the physical pointing device, while on a aparallel path the main loop is launched. This loop begins with drawing140 the hierarchy on the screen.

Step 120 monitors the user input device to detect a change in thephysical user-input device's “state”—position and button state. A changemay require an update 122 of the emulated joystick position 130. If achange in the emulated joystick position is detected at 124, theemulated joystick is redrawn at 126. This is illustrated below withrespect to FIG. 15.

Returning to the main loop (the right side of the drawing), the emulatedjoystick is monitored at 142 for any displacement from its centerposition. When the displacement is non-zero in any dimension, thedisplacement is mapped by 144 to an incremental change in hierarchy“Focus”. “Focus” means where in the hierarchy the user's current view ofthe hierarchy is centered. Focus is defined as a two-element vector,{Depth,Position-in-Level}. Hierarchy “Depth” is like hierarchy level,but is permitted to take floating-point values between the integers towhich “level” is confined. “Position-in-Level” is a position among thenodes in a level, the leftmost having Position-in-Level 0.0, like anindex, but permitted to take floating-point values between integralindices. For instance, a Focus of {1.1,1.5} in the sample hierarchy ofFIG. 1 means that the user view is centered between levels 1 and 2 butcloser to level 1, and horizontally midway between nodes 24 and 28.

As will be seen in FIG. 8, an alternate method of specifying positionwithin a level has two parts:

-   -   “FocalNode”, a reference to that node in level <integral        component of Depth> with an index of <integral part of        Position-In-Level>; and    -   “horiFract”, the fraction of that node appearing to the left of        the center of user view.        “FocalNode” therefore corresponds to the integral component of        Position-in-Level and “horiFract” is the fractional component.        It is this method of specifying position within a level which we        will use in descriptions which follow.

The exact mapping 144 of emulated joystick displacement to a change inFocus {dDepth,dFract} depends upon the configuration of the embodiment,but for a configuration in which hierarchy levels are arrangedhorizontally and hierarchy descent/ascent are shown vertically, themapping may be as simple as

-   -   depth=k1*vertical displacement of emulated joystick    -   dFract (change in horiFract)=k2*horizontal displacement of        emulated joystick.        where k1 and k2 are numbers fixed during navigation. For a        configuration in which hierarchy levels are arranged vertically,        dDepth would follow the horizontal joystick displacement and        dFract would follow the vertical displacement. Additional        mapping tweaks found to be useful include:    -   greater-than-linear mapping to allow both fine control and        high-speed navigation from an emulated return-to-center        controller with limited travel.

One implementation uses a dDepth proportional to the square of emulatedcontroller displacement in one direction, for instance. This allows fora navigation speed “dynamic range”—ratio of fastest to slowest non-0speed—of 12×12 in the case where emulated controller displacement in onedimension varies from −12 to 12 pixels.

-   -   attenuating diagonal navigation, particularly in the direction        of hierarchy ascent. During hierarchy ascent the user typically        does not intend any lateral navigation at the same time. During        hierarchy descent diagonal navigation is often desired but can        be attenuated to minimize risk that a user might sense losing        control.    -   limiting emulated controller movement to one dimension at a        time. This suggests an alternative rendering of the controller.        FIG. 15 shows the “joystick” look and some alternatives. One        implementation allows the user to select among alternative        controller “look and feel” designs to find one most suitable to        the user.    -   a mapping of displacement to dFract which is a function not only        of displacement but which is sensitive to the fractional        component of Depth in a way which eliminates 2^(nd)-order        discontinuities in the rendered location of nodes, given        constant emulated controller displacement. (Implementations we        are describing prohibit by design 1^(st)-order discontinuities        in node location or size regardless of controller state; this        enhancement further eliminates a 2^(nd)-order discontinuity.)

After adding the incremental change dDepth to Depth in 146, step 148updates the “vertical” parameters using the logic shown in FIG. 7,discussed below. “Vertical” here means “in the direction of hierarchydescent or ascent”, which may be visually either horizontal or verticaldepending upon the configuration.

After adding the incremental change dFract to horiFract in 150,“horizontal” (“in the direction from a node to its sibling”) parametersare updated in step 152 using the logic shown in FIG. 9, discussedbelow.

Step 154 tests if either Depth or horiFract has changed by more than apredefined threshhold since its last use in drawing the hierarchy. Ifso, the hierarchy is redrawn in step 140 using the logic shown in FIGS.10 and 11. The purpose of the threshholds is to reduce demands oncomputer power by not launching expensive redrawing operations forvisual differences small enough to approach imperceptibility.

In either case, the main operation loop continues with the monitoring142 of the emulated controller's position. This loop is performed atnearly constant time intervals. As the logic of 144 maps a giventwo-dimensional emulated controller displacement to a two-dimensionalFocus change per loop iteration, periodic iteration further maps it to atwo-dimensional Focus velocity.

FIG. 6 shows how the display area 402 is to be allocated among somenumber of hierarchy levels by the logic in FIG. 7. 406 shows onepossible allocation to three adjacent levels we call “hiLevel”,“loLevel”, and “be loLevel”, where the parent of a loLevel node is inhiLevel and its children if any are in beloLevel. The allocated bandsmay lie partially outside (as with hiLevel) or completely outside (aswith hiLevel-1) the actual display area 402. The thickness of allocatedbands decreases geometrically with increasing level. For instance, ifthe ratio of thicknesses R_(th) of adjoining bands is 2.0, as in theexample shown, each level is allocated half the space allocated to itsparent level. Note that as the user descends the hierarchy, a level ofnodes is very small at its first appearance and gains visual weight asit approaches the focus; this seemingly gradual appearance of each nodepermits a visually smooth navigation experience.

The geometric relationship among band thicknesses is accomplished byarranging the lines delimiting the bands “exponentially”. Morerigorously, define a “Virtual Display Area” 404 of which the actualdisplay area 402 is but a fraction H_(ADA)/H_(VDA) between 0.5 and 1.0.Then the distance to the line at the top of level N from the bottom ofthe Virtual Display Area is:Virtual Display Area height*R_(th) ^((Depth−N))(remembering “Depth” is one component of Focus), or for our example,Virtual Display Area height*2.0^((Depth−N))These level-delimiting lines will fall outside (above) the display areafor N much less than Depth, and for increasing N, the lines approach thebottom of the Virtual Display Area, falling below the actual displayarea. The implementation illustrated chooses H_(ADA)/H_(VDA)32 ¾ so thatexactly two complete levels are shown. If Depth were a multiple of 1.0,hiLevel and loLevel would then be assigned the top ½ and next ¼ of theVirtual Display Area, totalling all of the actual display area. In thecase illustrated, all of loLevel and parts of hiLevel and beloLevel fallin the actual display area. For any choice of H_(ADA)/H_(VDA)<=¾, onlythe two lines 408 and 410 delimiting loLevel need be calculated for thepurpose of drawing, as all others fall outside the actual display area.Drawing is sped up by the fact that at most 3 levels of nodes areinvolved. For implementations having access to greater resources,H_(ADA)/H_(VDA) may be chosen closer to 1.0, so that more of thedelimiting lines 412 fall within the actual display area, and morelevels and many more nodes need to be represented.

Turning to FIG. 7, we see the logic 148 which accomplishes the verticalallocation illustrated in FIG. 6 in the case R_(th)=2.0,H_(ADA)/H_(VDA)<=¾. This logic is invoked from the main operation flowof FIG. 5 when Depth has changed by a small fraction of 1 or −1, andserves to precalculate some drawing parameters. At step 418, Focus Depthis first forced to be greater than some minimum which is configurablebut is typically near 1.0 and to be less than a maximum which is tied tothe greatest level of any node loaded. Step 420 then determines whichlevels will be represented in the display area, or in other words whatintegers correspond to “hiLevel”, “loLevel”, and “beloLevel”. Theremainder from this rounding operation “vertFract” will be saved todetermine the placement of the delimiting lines in step 428 and forlater drawing calculations. A check 422 is made to see whether hiLevelhas changed; that is if Depth has crossed an integer boundary. In mostcases it has not. If hiLevel has decreased, horizontal parameters arechanged in step 424: FocalNode's parent node becomes FocalNode, andhoriFract is loaded with what fraction the former FocalNode's childindex, augmented by the former horiFract, is of the parent's children.If hiLevel has increased, horizontal parameters, are changed in step426: the FocalNode child with a child index of horiFract times thenumber of children, rounded, becomes FocalNode, and the remainder fromthe rounding becomes horiFract.

Step 428 now calculates the placement of the delimiting lines. This wasstated above to beVirtual Display Area height*2.0^((Depth−N))from the bottom of the Virtual Display Area. The formulae in 428calculate the more useful distances from the top of the display area,hence the “1−”. These distances “hiLevelBot” and “loLevelBot” are shownas 408 and 410 on FIG. 6. For H_(ADA)/H_(VDA)=¾ this need only becalculated for the two integral levels N for which Depth-N is between 0and B2.

FIG. 8 illustrates what “horizontal” allocation must do. The displayarea 520 having been “vertically” allocated into bands for the hierarchylevels hiLevel 522, loLevel 524, and beloLevel 526, each band must befurther allocated to specific nodes. “Focus” can be thought of as animaginary point in the hierarchy that corresponds to the center of thedisplay area 532. “FocalNode” is that node which will be drawn toinclude this center; the shaded box 534 is its allocation. “horiFract”is the ratio of FocalNode appearing to the left of the center,0.0<=horiFract<=1.0. That is, horiFract is the ratio of the solid blackline 536 to the width of FocalNode's rectangular allocation 534.“Horizontal” allocation occurs mostly during drawing using the logicillustrated in FIGS. 10 through 13. FIG. 9 shows some precalculationwhich is performed after an incremental change to horiFract: If at 552horiFract has spilled over and is no longer>=0, step 556 replacesFocalNode with the node to its “left” in the hierarchy and 1.0 is addedto horiFract, unless there is no left node in which case step 558 clipshoriFract to 0.0. If at 562 horiFract has spilled over and is nolonger<=1, step 566 replaces FocalNode with the node to its “right” inthe hierarchy and 1.0 is subtracted from horiFract, unless there is noright node in which case step 568 clips horiFract to 1.0.

Horizontal allocation is driven by determining the widths of nodes inlevel loLevel as they are drawn, first for FocalNode, then iteratingthrough nodes to its left until the display area is used, then iteratingthrough nodes to its right. The display area width required for a nodedepends on the width required to render it and the sum of renderingwidths of its children. The geometric weight given to each of these twofactors varies with the fractional component of Depth. As illustrated, aloLevel node is narrower than another having more children (inbeloLevel) but its children are wider than those of the other node. FromloLevel width allocations:

-   -   child node width allocations are simply prorated.

For implementations which can show more than three levels of nodes at atime (H_(ADA)/H_(VDA)>¾), proration continues beyond beloLevel. Forinstance, if a loLevel node has width W and 3 children each with 3children, each child has width W/3 and each grandchild has width W/9allocated.

-   -   parent node (in hiLevel) width allocations are summed from their        children's widths. In FIG. 8, four loLevel nodes have one parent        540 and the last has another 542.

Before turning to the drawing logic in FIGS. 10 and 11 whichaccomplishes this, note the horizontal-parameter terminology that willbe used: “left” and “rite” are the left and right boundaries of a node'sdisplay allocation, marked by 544 and 546 for FocalNode on FIG. 8.

The drawing logic of FIGS. 10 and 11 can be roughly divided into areasdrawing FocalNode, drawing nodes to its left, then drawing nodes to itsright. The software routine “loDraw(node, horizontal position, fractionto left)” which will be described in reference to FIG. 12 is invoked foreach loLevel node (steps 612, 618, 652) not only to draw it but tocalculate and return its “left” and “rite” boundary locations, and todraw its children. After each loLevel node is drawn, its width is addedto that of an accumulating parent node “hiNode”, either a new one (steps614, 630, 660) or an existing one (steps 622, 656). A new “hiNode” isneeded when the loLevel node just drawn has a parent which is nothiNode, as checked at 620 and 654. At this time, and at the end of theroutine, the existing hiNode is drawn using the software routine“hiDraw(node)” (steps 626, 642, 658, 662).

FIG. 12 illustrates the logic of software routine “loDraw(node,horizontal position, fraction to left)”. Step 714 outlines the node andstep 718 draws the node-specific representation concentric with theoutline. For each child, step 720 outlines the node and step 724 rendersit in the case where the outlined area is large enough to hold therendering. How many outlined nodes are fully rendered for any givenFocus depends upon the space demands of rendering each, upon the displayarea dimensions, and upon how quickly the hierarchy fans out. However,for typical applications, nodes on three levels are always outlined andare fully rendered about half the time, and nodes on only two levels arefully rendered the other time.

Prior to the outlining and drawing, loDraw( ) must first (step 710)calculate the node's allocated display width “Wide” given the fractionalcomponent of Depth “vertFract”, the number of child nodes, and a targetrendering width using the formulatarget render width*childcount^(vertFract)It must then (step 712) convert “Wide” and the incoming parameters“horizLoc” and “fractionLeft” to “left” and “rite”, its left and rightedges. “horizLoc” is a horizontal location; it specifies the left edgeif “fractionLeft” is 0, right edge if “fractionLeft” is 1, and somepoint in between for 0<fractionLeft<1.

To “draw node-specific rendering” may mean invoking primitive code torender text and/or graphics. However for performance reasons in someimplementations this means copying a prerendered image to the outlinecenter, so that the time spent in rendering each node need only beincurred once.

FIG. 13 illustrates the much simpler logic of drawing a hiLevel node:outline the node, then draw its node-specific rendering.

If calculations of level-delimiting lines and node widths would placesome of a node outside the actual display area, node outlines are madeto respect the boundaries of the actual display area. Centeringnode-specific rendering in this reduced area minimizes the number ofcases in which node-specific rendering overflows the actual displayarea. Such cases can be completely eliminated or can be permitted bychoices in defining “target render width” and “min render width” used insteps 710 and 716.

It is not a part of drawing, but associated with outlining any node instep 802 on FIG. 13 and steps 714 and 720 on FIG. 12, the node ischecked for an unread input source. If it has one, software routine“hierarchyLoad” is launched to asynchronously populate the hierarchybeneath this node from hierarchy information read from the source. Thehierarchy information loaded by the first invocation of hierarchyLoad,which populated the hierarchy under the dummy root node, may not be thecomplete hierarchy for this application. The hierarchy server maydeliver only a portion of the hierarchy information, with references toadditional portions. This can allow a user to widely navigate an immensehierarchy while triggering the transfer of only a small fraction of thehierarchy information from the hierarchy server to the client. Theportions are loaded on demand but before they are actually needed forrendering by calling for them when their parent nodes are firstoutlined.

Division of the total hierarchy into smaller portions can beaccomplished by human or automated extraction of the information intoseparate files resident on the hierarchy server. Alternatively, thehierarchy server can automatically divide the hierarchy into portions,each with a magnitude appropriate to the network bandwidth, andautomatically generate references to information “files” describingsub-hierarchies of the total hierarchy. That is, the “files” sent overthe network may never exist in the file format.

We call the delivery of a hierarchy in portions and on demand “hierarchystreaming”, whether division into portions is prior to or a part ofserver operation. “Hierarchy streaming” is comparable to “streaming” asthe term is generally applied to the transmission of data incrementallyover a network concurrent with use of the (already-received) data by theclient, as for instance when sound information is played by a clientcomputer as additional sound information is still being transmitted.However, hierarchy streaming differs in that the information deliveredis of more than one “dimension” and there is a strong likelihood thatnot all of the information will be needed at the client. Thereforetwo-way communications are useful in hierarchy streaming. Not only mustthe server deliver information, but the client must request differentportions of the hierarchy as they are needed. A hierarchy-streamingperformance enhancement is to maintain exactly two connections (one foreach direction) between the client and the server, rather than openingand closing a connection for each portion.

The minimize size of streamed portions may be a fixed server parameter.For a performance enhancement, the hierarchy server may adjust theminimum portion size in response to network characteristics as they varybetween clients and over time. For instance, a server receivingrapid-fire requests for portions from one client might infer ahigh-bandwidth connection and deliver larger portions to that client,and it might infer a high error rate from repeated requests for the sameportion from another client and deliver smaller portions to that client.

Here is how a hierarchy server might serve a request for hierarchyinformation while respecting a minimum portion size:

-   -   From the request, identify the parent node of the hierarchy or        subhierarchy for which information is requested.    -   Copy that node's information from the overall hierarchy        data—which may be in a database, one or more files, or an        in-memory data structure—to a new hierarchy data structure, as        the root node information.    -   Among information copied for each node can be a reference to the        portion of the hierarchy for which that node is the root. A        “reference” to a portion is information from which a request for        the portion to the server can be constructed. For this first        copy, the reference simply reflects the original hierarchy        information request.    -   Among references that have been added to the new hierarchy data        structure and still remain, take that added earliest, remove it        from the data structure, and copy information for all child        nodes (of the node containing the reference) from the overall        hierarchy data to the new hierarchy data structure.

Again, the copied information may contain references.

-   -   Repeat the previous step while references remain and while the        new hierarchy data structure is smaller than the minimum portion        size.

FIG. 14 shows the hierarchy-loading process from the client point ofview. Software routine “hierarchyLoad” is passed a node that has anassociated “unread input source”. This is a string that names a path,such as a “URL” for internet access or a filename, to a hierarchydefinition file. The hierarchy source could also be a database, a datastructure, or another program, but here we will describe transfer of afile over the internet. Step 832 “opens” the source or makes itavailable for reading. In a client-server context, this “open”constitutes a request to the server to provide the hierarchyinformation. In a loop, step 836 is used to read each line, untilfailure to read detected at 838 terminates the routine at 840. Each linedescribes one node, specifically:

-   -   The node level relative to the top node level of the file. This        is a relative specification so that hierarchy definition files        can be combined by simply referring to a hierarchy definition        file from a node specification in a “parent” hierarchy file. The        top level of the “child” hierarchy definition file is then one        more than the referring node's level. In this way hierarchy        modules can be readily split and recombined by humans using        editors. In some implementations, hierarchy definition files are        human-readable and editable; the format facilitates this by        using line indentation to specify relative level. Indentation        increased from the previous line indicates a level one greater;        indentation decreased to a previously used indentation indicates        the level previously indicated by the indentation. For instance        a file like this        -   Node 1            -   Node 2                -   Node 3        -   Node 4    -    would cause node 1 and 4 to be placed at level N, node 2 at        level N+1, and node 3 at N+2, where N is one greater than the        level of the node referring to the file.    -   (optional) text used as a node “label” for rendering the node    -   (optional) a path to a graphic “image” for rendering the node.        If both a label and a graphic are specified, the label is        rendered on top of the graphic. A current implementation uses        the format “<image=URL>” for this information.    -   (optional) a specification of an “action” to take if the user        selects the node, as by “clicking” it with a pointing device.        Each “action” is interpreted by software communicating in an        application-dependent way. The format “<action=URL>” can be used        for this information. Some implementations render those nodes        which have associated actions with a push-button-like appearance        to suggest to the user that clicking the screen appearance will        have an effect.    -   (optional) a “hier” reference specifying the source for a        hierarchy to be loaded beneath this node. A current        implementation uses the format “<hier=URL>” for this        information.    -   (optional) any number of “<key=value>” specifications assigning        a short string to represent a long string so that “action”,        “image”, and other specifications can use a sort of shorthand.        Such assignments are valid for such specifications for all of        the node's descendants.        Step 842 represents the parsing of node level. Parsing of the        other specifications is shown in steps 844 and 846.

At step 848, the new node is placed in the hierarchy data structure as achild of the node added most recently (by this execution instance ofhierarchyLoad) at the previous level, and this node is recorded to bethe most recently added at this level. This can trigger a redrawing ofthe hierarchy in cases where the affected parent node is currently beingdisplayed.

FIG. 15 shows a preferred screen layout of an emulated return-to-centercontroller (a pointing device like a joystick which returns to a restingposition when it is released) and a few alternatives.

Referring to the “control stick” view 920 we describe how areturn-to-center controller is emulated when the user has available anon-return-to-center pointing device with a button such as a mouse.Navigation begins when the user guides the mouse to “drag” displayobject 922, here an oval representing the top of a control stick, in anydirection from its rest position 924 in the center of the region 926(shown shaded) in which the object may travel. “Drag” means that theuser clicks on the object and moves the mouse with its button depressed.While the button is depressed, the emulation moves display object 922 tofollow the pointer as limited by the travel region. Specifically, if the“cursor” 928—an on-screen representation of the position of a user mouseor other pointing device provided by an operating system—is at theposition shown in view 920 when the button is depressed, and the usersubsequently causes it to move to its position shown in view 930 withthe button still depressed:

-   -   Step 120 “Monitor User Input Device” of FIG. 5 detects these        events.    -   Step 122 “Update Emulated Joystick Position” then moves display        object 922 by the same amount in each dimension that the cursor        has moved, and will record this current displacement, the vector        932.    -   This displacement of the emulated controller is then used by        other parts of the invention as if it were the displacement of a        physical return-to-center controller.        Step 120 also detects the release of the mouse button, at which        time step 122 moves the display object 922 back to its rest        position centered at 924 and updates the emulated controller        displacement to {0, 0}.

The further the object is dragged from the rest position, the greaterthe emulated controller displacement, and the more rapidly the Focuschanges, by the mapping 144 of FIG. 5.

By always rendering the “stick” part of the control stick with one endat the bottom of the travel region and the other end near the center ofdisplay object 922, the image approximates the look of a control stickviewed from above but not directly above, so that in view 930 the stickappears foreshortened.

Each of the following alternative layouts also show a round draggableobject at its rest position in a shaded region of allowed travel.Alternate layout 940 is for a vertically displayed hierarchy with thehierarchy root being to the left. It shows a round object which can bedragged left in the direction of hierarchy ascent or in any combinationof the opposite and perpendicular directions. Lateral navigation incombination with hierarchy ascent is prohibited. Layout 950 shows alayout that completely restricts travel to one dimension at a time.Layout 960 splits this into two separate scrollers, each of which is“return-to-center”.

FIG. 16 shows a sample sequence of views presented to a user navigatinga hierarchy by nudging control stick 992 away from its rest position inthe center of the round area surrounding it. The illustratedimplementation is configured horizontally with the top of the hierarchyat the top of the view. The views shown here are only samples from theanimated sequence of views the user sees. While viewing view 994, theuser nudges control stick 992 downward to descend the hierarchy, then atabout the time of view 995, the user moves control stick 992 to the leftto swing left as well as downward through the subnodes of the nodelabeled “Computers and Internet”. At about the time of view 996, theuser is cruising due left to center “Build Your Visual Studio 6.0Library”. Then as shown below view 997, control stick 992 is againpushed slightly downward to bring the child nodes into view 997. At thispoint the user releases control stick 992 and it returns to its homeposition as shown.

FIG. 17 shows a sequence of six views 972 through 977 presented to auser navigating indexed data (in this case, a dictionary), where theimplementation is configured vertically with the hierarchy root at theleft side of the view. Again, the views shown here are only a samplingof the animated sequence of views the user sees. In this sequence, theuser is drilling directly “down” in the hierarchy by pushing the controlstick to the right. As the non-leaf nodes are of no interest to the userother than as an aid to navigation, they are not “active”. Only the leafnodes appearing in view 977 are active and appear as buttons.

FIG. 18 illustrates a hypothetical deployment at a single web site toallow rapid seamless navigation of that site as it would appear in abrowser, window. Visually, a page at the site is composed of a mainframe 986 and a navigation frame 984. A vertically-oriented view of ahierarchy 980 and an emulated control stick 992 appear in the navigationframe. The hierarchy in this case is the hierarchical organization of aweb site. Each node corresponds to a page in the site hierarchy whichcan be loaded into the main frame, and a node's associated action isinterpreted to cause a load of the corresponding page into that frame.We see the site just after the button labeled “Museum Review 1998” wasclicked, causing the corresponding content to be loaded into the mainframe.

Other embodiments are within the scope of the following claims.

The invention is easily applicable to a wide range of uses because:

-   -   Hierarchies are ubiquitous.    -   Hierarchy geometry is input as part of the hierarchy information        rather than hard-coded in an implementation.    -   Node-specific appearances are input as part of the hierarchy        information rather than hard-coded in an implementation.    -   Node-specific actions are input as part of the hierarchy        information and are interpreted by a surrounding application in        an application-specfic way rather than by the invention.

The invention can be applied to navigating a file system. For suchpurposes a node-specific action might be, for files, to open a file in afile-type-specific way, and for directories, no node-specific action isnecessary as navigation itself “opens” the directory. The invention canbe applied to file systems in a network logically combined as if theycomprised one large file system.

The invention can be applied to allow easy user navigation of ahierarchically organized set of pages at a large web site, asillustrated in FIG. 18. The small display area demanded by the inventionto navigate a hierarchy of any size can be placed in a “navigationframe” of a browser window, allowing the user to browse the site andfrom there control the content of a larger “main frame” of the window.More generally, the invention can be likewise be applied to allow easyuser navigation of any hierarchically organized set of web pages whichmay reside in a large number of different sites. For such purposes, anode-specific action places the web page advertised by the selected nodein the main frame. The invention can be deployed for such an applicationby several means, including as a “java applet”, as a “plug-in”, or as apart of the browser itself.

The invention can be applied to navigating a document with an outline. Anode-specific action in this case places the user in the associated partof the document. “Document with an outline” includes well-outlined bookssuch as most textbooks, Bible versions which have been divided intobook, chapter and verse, and many reference and how-to books.

The invention can be applied to navigating a flat list by “indexing” thelist or file. That is, a hierarchy can be created in which the lastlevel is comprised of leaf nodes associated with the goal of navigation,the elements of the list. (For a dictionary example, leaf nodes areassociated with words.) All other nodes are synthesized and labeled toprovide reliable signposts for getting to the right leaf nodes. (In thedictionary example, these would identify alphabetic ranges like“Aar-Byz”.) The non-leaf nodes then would have no node-specific action.A leaf node's action for a dictionary might be for the computer to printor to speak a definition or a translation. The action for a contact listleaf node might be to print an address, start an email message, or dialthe phone. FIG. 17 illustrates such alphabetic navigation of a wordlist.

The invention can be applied to navigation of an XML file, either toedit the file or to create a flexible application driven by the XMLfile.

The invention can be applied to user navigation of an encoded hierarchysuch as the Dewey Decimal System. In this case a node-specific actionmight bring up information about the book.

The invention can be applied to allow easy user entry of postaladdresses or other locations by browsing hierarchically arrangedgeographic regions. For instance, child nodes of a node labeled “NewEngland” might be labeled with state names.

The invention can be applied to allow rapid user entry of numeric datasuch as a postal code, where the child nodes of a node labeled “347”would be “3470”, “3471”, “3472”, “3473”, “3474”, “3475”, “3476”, “3477”,“3478”, and “3479”, and a postal-code hierarchy could thus besynthesized.

The invention can be applied to allow easy user selection of categorizedproducts. A recorded song for instance might be categorized at the toplevel as “music”, then “rock/pop”, then “hip-hop”, then by recordingartist, then by recording, then by track title.

The invention can be applied to entry of text from any set ofcharacters. For a large character set such as “hanzi” used for theChinese language, characters can be categorized into a hierarchy usingconventional indexing methods (Chinese dictionaries are typicallycategorized by number of strokes), or in some other way, such ascategorization by visual similarity. The invention is particularlyapplicable when a keyboard is unavailable or impractical for text entry.

The invention can be applied to allow easy user navigation of contentwhich is not hierarchical in its native mode (such as a largeunorganized site, a corpus of literature, or the entire web) but uponwhich a hierarchy can be imposed using “self-organizing maps” or othersimilarity-seeking technology.

1-55. (canceled)
 56. A method of displaying hierarchically organizedinformation in a two-dimensional space, the method comprising displayingrepresentations of nodes of a hierarchy in a two-dimensional space on adisplay, each node representation fully occupying a subspace within thespace, and allocating the space entirely to the subspaces, theallocation of the display space to the subspaces being dependent on atwo-dimensional value representing a focus of a view of the hierarchydisplayed to a user, such that a position and dimensions of the portionof the space allocated to each subspace of the display space vary onlyby an arbitrarily small amount for an arbitrarily small change in thetwo-dimensional focus value.
 57. The method of claim 56 in which thetwo-dimensional value comprises a floating-point value.
 58. The methodof claim 56 in which one dimension of the two-dimensional valuerepresents a depth of the hierarchy, and the extent of the display spaceallocated to a subspace in a dimension that represents the hierarchydepth is a function of the corresponding node's focus-relative depth,the focus-relative depth comprising the difference between the node'sdepth in the hierarchy and the component of a user-indicated focus inthe dimension corresponding to hierarchy depth.
 59. The method of claim56 in which the extent of the display space allocated to a subspace inthe dimension that does not represent the hierarchy depth is, for nodeswithin a central range of focus-relative depth, a function of the node'sfocus-relative depth and the number of the node's child nodes, and fornodes that are children to nodes within the central range, a function ofthe extent of the space allocated to the node's parent and the number ofthe node's siblings and its order with respect to them, and for nodesthat are parent to nodes within the central range, a function of theextents of its child nodes.
 60. A method comprising receiving at aserver a request from a client for information about a hierarchy, inresponse to the request, providing to the client information about onlya portion but not all of the hierarchy, the portion including referencesto information about other portions of the hierarchy, and determiningthe size of the portion to be provided to the client adaptively based onparameters for optimizing communication between the server and theclient.
 61. The method of claim 60 in which each of the portionscomprises a sub-hierarchy of the hierarchy.
 62. The method of claim 60in which the server automatically builds a hierarchy definition portionthat is as near as possible in size to a given minimum portion size. 63.The method of claim 60 in which the server generates references tosub-hierarchies and includes them with definitions of nodes of theportion provided.